Data structures for use with environment based data driven automated test engine for GUI applications

ABSTRACT

The invention relates to data structures for use with an environment based data driven test engine for computer programs which have a graphical user interface (GUI). The data structures are used in connection with a scriptable GUI test tool. The tool generates a GUI map (or includes a utility which generates a GUI map), at least one environment definition (parameter) file, at least one test data (driver) file, and an automated test engine. A separate environment definition file is provided for each feature of the GUI. Each environment definition file provides the abstract details required by the test engine in order to support common processes for different applications. The test data file is organized into rows of data where each row defines a single test and each column represents a parameter. The automated test engine is composed of a plurality of library modules written in the scripting language of the scriptable GUI test tool. The ATE is driven by the test data file and calls upon the GUI map and environment definition file. According to the presently preferred embodiment, the scriptable GUI test tool is WinRunner®. The environment definition files and the test data files are preferably generated with a spreadsheet program such a Microsoft Excel® and saved as comma delimited text files.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The invention relates to methods and apparatus for testingcomputer programs. More particularly, the invention relates to datastructures for use with an environment based data driven test engine forcomputer programs which have a graphical user interface (GUI).

[0003] 2. Brief Description of the Prior Art

[0004] Computer programs consist of lines of individual instructionsthat are read and executed by a processor. Early computer programs werenot “interactive”. They consisted of a set of instructions that weredesigned to be read and executed starting with the first instruction andending with a last instruction. If one of the instructions contained anerror, the processor would halt the program when it tried to execute thedefective instruction. The programmer would then need to review all ofthe instructions to determine which one was defective. Although thistask of manually “de-bugging” a computer program was tedious, it waspossible because early computer programs were relatively short.

[0005] As computer programs grew in length and complexity, automatedde-bugging tools became necessary. An early de-bugging tool would simplyidentify which instruction caused the program to halt. This wasgenerally sufficient for debugging a simple linear program, but in thecase of looping programs, an instruction might function in some modesand malfunction in other modes.

[0006] Today, even “simple” computer programs are very large, oftenconsisting of millions of instructions. Moreover, most of today'scomputer programs are “interactive”, i.e. require interaction with theuser of the program. Thus, a defective instruction in the program mightonly be discovered in the case of a particular user action. Furthermore,most of today's computer programs have a graphical user interface (GUI).A GUI typically includes various elements, referred to as “objects”,including “windows”, “menus”, “icons”, “dialog boxes”, “lists”, “radiobuttons”, “check boxes”, “text entry fields”, etc. De-bugging a programthat has a GUI is doubly complex because, in addition to theinstructions for the program to carry out computing tasks, the programalso includes instructions for managing the GUI.

[0007] There are several known testing tools for de-bugging GUIapplications. One such tool is WinRunner® from Mercury InteractiveCorporation, Sunnyvale, Calif. WinRunner® is a testing tool whichverifies that GUI applications work as expected. By capturing, verifyingand replaying user interactions automatically, WinRunner® identifiesdefects in multiple processes.

[0008] With WinRunner®, tests are created by recording user actions. Asa test is recorded, check-points are created to compare expectedoutcomes with actual outcomes. Each time a test is recorded, a GUI mapis created. The GUI map contains a list of all of the objects and objectattributes used by the test. Each test is recorded using an editabletest scripting language (TSL).

[0009] A disadvantage of most GUI testing tools, including WinRunner®,is that a separate test script must be created for each GUI applicationfeature. Several thousand test cases (or steps) have to be executedmanually with manual and/or visual verification of test results.Repetitive manual execution of test cases is required in order to verifycorrection of faults or to re-verify functionality of an applicationafter any new production of the application under test. Record andreplay operations for generating repeatable test cases require testscript (code) modifications for each error found or new test caseidentified. The modifications themselves require thorough testing beforethe actual test result quality can be assured. New objects or fieldsthat are added to the GUI application or objects that are moved orremoved have a significant impact on all previously recorded test caseseven though the behavior of the application has not changed.

[0010] Generally, the principles of data driven testing in the prior artinclude data for automatic test execution according to preprogrammedsequences. However, the data provided to drive the testing does notinclude data that can be used to define the environment. Taken together,the environment and associated behavior of GUI objects in thatenvironment require specific code or test scripts to be generated andtested. New applications or modifications to an existing applicationunder test cannot be implemented without significant test softwaredevelopment. A significant investment in manpower is required toimplement, maintain and enhance the test software that is not reusable.

SUMMARY OF THE INVENTION

[0011] It is therefore an object of the invention to provide a datadriven test engine for GUI applications.

[0012] It is also an object of the invention to provide a data driventest engine for GUI applications which is environment based.

[0013] It is another object of the invention to provide a data driventest engine for GUI applications which is automated.

[0014] It is yet another object of the invention to provide a datadriven test engine for GUI applications which tests all of the featuresin a single test script.

[0015] It is another object of the invention to provide the maximumflexibility for test case generation, maintenance and execution requiredduring the development and test cycle of a GUI software project.

[0016] It is still another object of the invention to reduce theinvestment in manpower to implement, maintain and enhance automated testsoftware.

[0017] It is another object of the invention to provide a data driventest engine for GUI applications where modifications to the test engineare required only when a new behavior of an object on the GUI isintroduced.

[0018] In accord with these objects which will be discussed in detailbelow, the methods and apparatus according to the invention include ascriptable GUI test tool which generates a GUI map (or which includes autility that generates a GUI map), at least one environment definition(parameter) file, at least one test data (driver) file, and an automatedtest engine. As used herein when it is stated that a GUI test toolsgenerates a GUI map it is to be understood that the the GUI test toolmay provide a separate utility which generates the GUI map.

[0019] A separate environment definition file is provided for eachfeature of the GUI. Each environment definition file provides theabstract details required by the test engine in order to support commonprocesses for different applications. Because the test engine is nothard coded to know the details of the application or object beingtested, specific variables are initialized and defined as external datavia the environment definition file. Information such as ApplicationName, Launch Menu, Primary Window identification, Tab and related tabwindows are identified in the “Environment” section of this file. Theindividual fields that appear in the application object are also definedin this file using the “Parameters” section. The behavior of theparameter is defined by assigning a “Type” definition that has alreadybeen implemented in the test engine. It is possible to maintainapplication version compatibility in a single environment definitionfile by identifying parameter elements that are new to a specificversion of an application. The values found in the environmentdefinition file are tightly bound to the logical names that are used inthe GUI map.

[0020] The key to the structure of the test data file is the “Parameter”section of the environment definition file. The test data file isorganized into rows of data where each row defines a single test andeach column represents a parameter. Occasionally, multiple rows of dataare required in order to facilitate or verify the results of anindividual test. The data begins with a definition of the default valuesthat are expected for each field (parameter). This single line of datais followed by one or more rows of individual data driven tests. Eachrow consists of standard fields and the data specific for each field ofthe object being tested. Standard fields include a Test ID, Preamble andPostamble action, Expected Result indication and a Comment. Preamble andPostamble actions are usually application specific and represent useractions required to establish a starting point for a test and the actionto perform to execute the desired test. The test case ID is reported ina log file for tracking purposes. The expected results field indicateswhether the test will pass completely or fail during data entry, duringthe execution of the preamble, postamble or during verification afterthe postamble action has been executed. Data that appears in theindividual fields of a data driven test are specific for the parameter,operation or the use of the field. Fields can be ignored, changed, leftalone or ignored for Query operations. Data can also represent multiplecolumns of a table structure.

[0021] The automated test engine (ATE) is composed of a plurality oflibrary modules written in the scripting language of the scriptable GUItest tool. The ATE is driven by the test data file and uses the GUI mapand environment definition file.

[0022] According to the presently preferred embodiment, the scriptableGUI test tool is WinRunner®. The environment definition files and thetest data files are preferably generated with a spreadsheet program sucha Microsoft Excel® and saved as comma delimited text files for use bythe ATE.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023]FIG. 1 is a schematic architectural overview of the invention;

[0024]FIG. 2 is a screen shot illustrating the layout of a driver fileaccording to the invention;

[0025]FIG. 3 is a flow chart illustrating the steps in creating a driverfile;

[0026]FIG. 4 is a screen shot illustrating the layout of a parameterfile according to the invention; and

[0027]FIG. 5 is a flow chart illustrating the steps in creating aparameter file.

BRIEF DESCRIPTION OF THE APPENDIX

[0028] The included CDROM appendix contains the following files:

[0029] /

[0030] VoiceStation.xls

[0031] PeripheryBoards.xls

[0032] Engine/

[0033] Actions

[0034] Common2All

[0035] CustomSupport

[0036] General

[0037] HDMS_CM_ZincInit

[0038] obj_main

[0039] ParmSetCheck

[0040] PopUpHandler

[0041] Setbaselines

[0042] SiteInitV52

[0043] TestInit.

DETAILED DESCRIPTION

[0044] Turning now to FIG. 1, the methods and apparatus according to theinvention include a scriptable GUI test tool 10 which generates GUI map12, at least one environment definition (parameter) file 14, at leastone test data (driver) file 16, and an automated test engine 18.According to the presently preferred embodiment, the GUI test tool 10 isWinRunner®.

[0045] As illustrated in FIG. 1, a GUI application 1 has y number offeatures. Each may include menu items, button bar items, windows, tabsand up to n number of GUI objects. GUI objects may include user inputinterface objects such as check boxes, radio buttons, text fields, etc.

[0046] The GUI map 12 generated by the test tool 10 includes the logicalnames and physical attributes for each of the GUI objects. A separateenvironment definition (parameter) file 14 is provided for each of the ynumber of GUI application features. Each parameter file 14 includes afeature environment definition which may include menus, windows, tabreferences and miscellaneous variables. The parameter file 14 alsoincludes up to n number of object environment definitions. Each objectenvironment definition includes a logical name, an indication of itsposition in the data file 16, x number of object behaviors, andmiscellaneous information. According to the presently preferredembodiment, the parameter file 14 is saved as a comma delimited textfile but it is created and managed as a spreadsheet file. The column androw structure inherent in a spreadsheet file make it easier to managethan a delimited text file. Two examples of a parameter file arecontained on the CDROM appendix as a tab in Microsoft® Excel®spreadsheet files entitled PeripheryBoards.xls and VoiceStation.xls.

[0047] A separate test data (driver) file 16 is provided for each of znumber of tests. The number of tests is selected by the user. Each testmay be simple or complex. Generally, each test data file includes a testcase ID, a preamble action, a postamble action, an expected result, atest case comment, and test data for each of n number of GUI objects.Two examples of a driver file are contained on the CDROM appendix as atab in Microsoft® Excel® spreadsheet files entitled PeripheryBoards.xlsand VoiceStation.xls.

[0048] A single test engine script 18 is provided for each GUIapplication to be tested. The test engine script 18 interacts with theWinRunner® application 10 and the GUI map 12. It also reads from theparameter file 14 and the driver file 16. According to a presentlypreferred embodiment, a test engine script is composed of a plurality oflibrary modules written in the scripting language of the scriptable GUItest tool 10. The test engine is driven by the test data file 16 andcalls upon the GUI map 12 and environment definition file 14 duringexecution. An example of a test engine script is contained on the CDROMappendix as a number of text files in the directory entitled “engine”.

[0049] Turning now to FIG. 2, the driver file (16 in FIG. 1) ispreferably created in a spreadsheet application and saved as a commadelimited text file for use with the test engine script (18 in FIG. 1).As shown in FIG. 2, the file is organized into rows of data where eachrow defines a single test and each column represents a parameter.Occasionally, multiple rows of data are required in order to facilitateor verify the results of an individual test. The data begins with adefinition of the default values that are expected for each field(parameter). This single line of data is followed by one or more rows ofindividual data driven tests. Each row consists of standard fields andthe data specific for each field of the object being tested.

[0050] The standard fields include a Test ID, Preamble and Postambleaction, Expected (Desired) Result indication and a Comment. Preamble andPostamble actions are usually application specific and represent useractions required to establish a starting point for a test and the actionto perform to execute the desired test. The test case ID is reported inthe log file for tracking purposes. The expected results field indicateswhether the test will pass completely or fail during data entry, duringthe execution of the postamble or during verification after thepostamble action has been executed.

[0051] Data that appears in the individual fields of a data driven testare specific for the parameter, operation or the use of the field.Fields can be ignored, changed, left alone or ignored for Queryoperations. Data can also represent multiple columns of a tablestructure.

[0052] More specifically, line 1 includes the directory structure forthe specific Excel® tab. Column “D” includes the Version ID forsubdirectory management. Column “F” includes the Test Suite Directoryname. Column “H” includes the Object ID—or, actually, the Name of thefile

[0053] Line 2 begins a History of Change section specific for the tab.Additional rows should be added in order to maintain a reasonable recordof the significant changes made to the data in this file. The Historyrecord should include the initials of the tester, the date of the changeand a brief description of he change.

[0054] Three lines are copied from columns of the parameter tab (FIG.4). All of the typeCode, logicalName and the fieldPosition columns areselected (and copied) from the parameter file and by using paste specialwith transpose enabled the columns are converted to rows. By selectingColumn “G” in the destination file as the paste destination theinformation is accurately reproduced for reference while generating datafor the test cases that will follow.

[0055] The standard data beginning with line 4 in FIG. 2 includes:Column “A”, Test Case identifier; Column “B”, Test Director ID; Column“C”, Preamble Action; Column “D”, Postamble Action; Column “E”, DesiredResult Code, Column “F”, Optional Comment; and Column “G”, begins thefield names.

[0056] Turning now to FIG. 3, the steps for creating a GUI test driverfile are illustrated in a flow chart. The process begins at 100. For thefirst row of the file starting at 102: a test case ID is defined at 104;an optional TD reference is entered at 106; the preamble action requiredto open or access the object is entered at 108; the postamble action, ifone is required, is specified at 110; the desired result is entered at112; an optional comment is entered at 114; and valid data for eachparameter in the object is entered at 116.

[0057] For the next row starting at 118: a test case ID is defined at120; an optional TD reference is entered at 122; the preamble actionrequired to open or access the object is entered at 124; the postambleaction, if one is required, is specified at 126; the desired result isentered at 128; an optional comment is entered at 130; and “ignore” isentered for each parameter in the object at 132. As described in moredetail hereinafter “ignore” is not always required in every fieldalthough sometimes it may be necessary.

[0058] In the last row of the test data, END is entered in Column A at134 and the file is saved at 136. As mentioned above, the file is savedas a comma delimited text file for use with the test engine script. Itwill be appreciated that the native spreadsheet file will also be savedfor further development.

[0059] The test case ID serves two purposes. First, it is used as atrace value in the log file that is created during execution of the testengine providing a means to relate the run results to the driver fileinput. Secondly, and more importantly, it allows test steps to begrouped into test cases providing a structure for a complete runsequence. A test case numbering convention is utilized to facilitateboth of these issues. Normally the first test case facilitates the“Opening” of an object or the initial access to the object to be tested.This test case is usually numbered “0” or “1”. Normally the last testcase facilitates the “closing” of the object under test or the exit fromthe object and it is best to provide a very high number as the Test CaseID e.g. “99999”. Since a test case may actually require more than onestep, or row, in the driver file to complete the requirements for atest, it is necessary to be able to group test steps into test cases.This is accomplished by utilizing the following sequence for numberingthe Test Case ID. 1.000 Initial step of a sequence for Test Case 1 1.010Second step of a sequence 1.020 Third step of a sequence 1.025 Secondsub step of step 2 of test case 1 1.090 Final step of the sequence fortest case 1 2.000 Begin test case 2 2.010 2^(nd) step 2.090 Final Stepof test case 2 etc.

[0060] Note that it is possible for any one of the individual steps tobe an actual “Test Case” as defined and documented in the Test Director.Therefore, an appropriate TdRef value can be assigned each of the steps.The TdRef value can be reused in each of the sequences since theTestCaseID is unique.

[0061] It is also possible to enter a “skip code” in a test case ID tobe able to skip a Test Case. This simplifies editing of the driver file.A skip code is identified at run time to indicate a specific set of testcases that should not be executed. According to one embodiment of theinvention, only one skip code is used at a time. According toalternative embodiments of the invention, multiple skip codes could beused and/or codes for performing (rather than skipping) tests arecontemplated.

[0062] A reference to Test Director test case name includes the subjectpath to resolve duplicate test case names.

[0063] The Preamble Action is used to establish the initial conditionsfor an individual “step”. It is expected that the preamble always works.Examples of preamble actions are: OpenBook, OpenChapter, SelectRow,NoAction, and Reload.

[0064] The Postamble Action defines the user action that will beperformed after the data has been entered. Examples of postamble actionsare: No Action, Apply, Commit, DeleteRow, Stop, Start, and Restart.

[0065] Expected Results defines what should happen as a result of thistest case. The test engine is currently designed to detect only onefault per line. The values of the Expected Result fields are used todetermine at which point a fault might (is expected) to occur. Thepresently preferred values for expected results are as follows:

[0066] =0 All phases of the test are expected to pass,

[0067] =1−999 An error is expected on input/outut of the fieldspecified,

[0068] =1000 An error is expected on execution of the Postamble action,

[0069] =1xxx A verification error is expected after the postamble actionon field xxx,

[0070] =2000 An error is expected during execution of the PreambleAction.

[0071] The Comment Field is optional and it is used for any necessarycomments that helps to clarify a Test Case. It will be appreciated thata comma should not be used in this or any other field since the filewill be saved to a comma delimited text file.

[0072] Special Data Values are provided for parameter manipulation.These include:

[0073] default=There is to be no data input into the field but thedefault value should be expected as a result of the specified action,

[0074] nochange=The value that is in the field as result of the previousaction should remain and the same value should be used as the expectedresult value for the specified parameter,

[0075] ignore=The field will not be changed and it will not be evaluatedfor expected result verification,

[0076] BlankQuery=The field is marked as NEED4Query in the parameterfile but for a specific test case it will not be utilized. This is usedwhen there are two fields that can be used for a query, but only onefield is required.

[0077] Turning now to FIG. 5, the basic format of the parameters(environment definition) file is shown in a screen shot of a spreadsheetfile. This file provides the abstract details required by the commonengine components in order to support common processes for differentapplications. Because the engine is not hard coded to know the detailsof the application or object (logical grouping of data for anapplication), specific variables must be initialized and defined asexternal data. Throughout the common engine functions, a reference tothe array structure called “VitalInfo”, is used to access these objectspecific variables. Information such as Application Name, Launch Menu,Primary Window identification, Tab and related tab windows areidentified in the “Environment” section of this file.

[0078] The individual fields that appear in the application object arealso defined in this file using the “Parameters” section. The behaviorof the parameter is defined by assigning a “Type” definition that hasalready been implemented in the test engine. It is possible to maintainapplication version compatibility in a single environment file byidentifying parameter elements that are new to a specific version of anapplication. The values found in this file are tightly bound to thelogical names that are used in the GUI map.

[0079] The definition of each object to be tested includes logicalnames, menus, expected windows, tab window names, links, and objectattributes. The parameter value types include edit, checkbox, list,displayonly, radio, and other types for specific applications

[0080] In particular, the parameter section of the file includestypeCode as supported by the test engine, logicalname as defined by theGUI map, fieldposition in numerical order, WinTabID (an environmentreference to the tab that the field appears on), queryCode indicatingthe field which is used for query operations, and VersionID.

[0081] The specific file structure definitions for the parameters fileinclude:

[0082] Column “D1”

[0083] VersionID=>For subdirectory management

[0084] Column “F1”

[0085] SystemDB=>Usually “Parameter”

[0086] Column “H1”

[0087] Object ID=>Name of the file or ID

[0088] HOC=>Author & Date

[0089] Referring now to FIG. 5, the creation of a parameter file isbegun at 200. At 202, the GUI macro, the tab save macro, and an existingparameter file are copied to a directory named xlsMasters. At 204, theobject GUI map is opened in Microsoft® Excel® and the GUI macro isexecuted. The result is copied and pasted into the parameter file at206. The environment section of the file is updated at 208. Theparameter section is built at 210 and the file structure is updated at212. The file is saved at 214 using the tab save macro.

[0090] As mentioned above, an exemplary test engine script is providedon the CDROM appendix in the directory entitled “engine”. The scriptincludes several files and functions which are described generally asfollows. Details of the functionality and the operation or use of theselibrary functions can be found in the header section of each moduleand/or function within each module. Each module also contains a HOC(History of Change) section.

[0091] The file entitled “Actions” contains the functions to handle thePreAmble and PostAmble actions of the test cases.

[0092] The function “ApplicationSpecific” contains general functionsthat are always application specific. These functions are utilized byother modules of the test engine script. They must always be modifiedfor specific operation of the application being tested.

[0093] The file entitled “Common2All” contains functions for all commonprocedure test cases. This module controls the main flow and logic forthe test engine.

[0094] The file entitled “General” contains miscellaneous functions tohandle loading of GUI map files, opening of the specific test object,file I/O and several wait functions required during test execution.

[0095] The function “EngineInit” is loaded automatically by WinRunner®(per the wrun.ini file). It initializes the physical GUI recognitionparameters that have been carefully defined for the application. Usuallythis module applies to ALL versions of the application under test.

[0096] The file entitled “ParmSetCheck” has two functions ‘SetField’ and‘CheckField’ which are used to handle the field value assignment andvalidation based on the input data. Application specific processing mustbe provided for recognizing error and success conditions.

[0097] The file “SiteInitVxx” varies between testers at each differenttest site (workstation/PC and User). It contains several global variabledefinitions that allow the individual tester to specify alternateparameters and characteristics that may be unique to the location and orpurpose of the test (e.g. test engine development as compared to testexecution). Most variables are defined as a constant in this file inorder to insure that they do not get overwritten during test processing.

[0098] The file entitled “TestInit” defines all global variablesrequired by the test engine.

[0099] The file “CustomSupport” provides the parameter Set and Checkfunctions required to support the Custom Grid Objects Tables or other3^(rd) party vendor supplied object constructions or class structures.

[0100] The file entitled “obj_main” provides the interface between theindividual Batch files and the test engine. Primarily it creates andinitializes some more complicated path variables based on previousdefinitions and the formal parameter that defines the “Object UnderTest”; forces a reload of the necessary library modules; and initializesthe environment, exception handling and the main test engine.

[0101] The function “PrePostActions_Init” declares and initializesglobal variables that are usually application specific for therecognition and processing of user actions. The values defined here areused in the test data drive files and are processed in the moduleentitled “Actions”.

[0102] The file entitled “Setbaselines” uses as input the Parameter File(environment and parameter definitions) for the Object Under Test. Theinformation from the parameter file is read into specific test enginedata structures in order to establish the “Environment” required by thetest engine. The data in the parameter file also defines the structureof the required data drive files.

[0103] The file “PopUpHandler” contains functions that are usedthroughout the test engine. These functions are specific to dealing withpop-up windows that are presented to the user during the course of theoperation of the application under test. Most of the logic in thismodule is application specific although the functions themselves aretest engine specific. Initialization, activation, deactivation,recognition and processing of Error, Warning and Information pop-upwindows is provided.

[0104] There have been described and illustrated herein methods andapparatus for environment based data driven testing of computer programswhich have a graphical user interface (GUI). While particularembodiments of the invention have been described, it is not intendedthat the invention be limited thereto, as it is intended that theinvention be as broad in scope as the art will allow and that thespecification be read likewise. It will therefore be appreciated bythose skilled in the art that yet other modifications could be made tothe provided invention without deviating from its spirit and scope as soclaimed.

What is claimed is:
 1. A data structure for use with a graphical userinterface (GUI) test tool to test a software application having a GUIwith different application objects, said data structure comprising: a)an environment part, said environment part including Application Name,Launch Menu, Primary Window identification, Tab and related tab windows;and b) a parameters part, said parameters part including individualfields that appear in an application object.
 2. The data structureaccording to claim 1, wherein: said individual fields include a “type”definition.
 3. The data structure according to claim 1, wherein:parameter elements that are new to a specific version of an applicationare identified.
 4. The data structure according to claim 1, wherein:values found in the data structure are tightly bound to logical namesthat are used in a GUI map.
 5. The data structure according to claim 1,wherein: the data structure is organized in rows and columns.
 6. Thedata structure according to claim 5, wherein: the data structure is acomma delimited text file.
 7. The data structure according to claim 5,wherein: the data structure is a spreadsheet file.
 8. A data structurefor use with a graphical user interface (GUI) test tool to test asoftware application having a GUI with different application objects,said data structure comprising: a plurality of rows, each row containinga plurality of columns, each row defining a single test and each columnrepresenting a parameter.
 9. The data structure according to claim 8,further comprising: multiple rows of data to facilitate or verify theresults of an individual test.
 10. The data structure according to claim9, wherein: each of said multiple rows of data begins with a first lineof data containing a definition of default values that are expected foreach parameter.
 11. The data structure according to claim 10, wherein:said first line of data is followed by one or more rows of individualdata driven tests.
 12. The data structure according to claim 11,wherein: each of said one or more rows includes standard fields and dataspecific for each field of an object being tested.
 13. The datastructure according to claim 12, wherein: said standard fields include aTest ID, Preamble a nd Postamble action, Expected Result indication anda Comment.
 14. The data structure according to claim 12, wherein:Preamble and Postamble actions are application specific and representuser actions required to establish a starting point for a test and anaction to perform to execute a desired test.
 15. The data structureaccording to claim 13, wherein: said expected result field indicateswhether a test will pass completely or fail during data entry, duringthe execution of the postamble or during verification after thepostamble action has been executed.
 16. The data structure according toclaim 13, wherein: data that appears in individual fields of a datadriven test are specific for a parameter, operation or use of saidfield.
 17. The data structure according to claim 16, wherein: at leastone of said fields includes an indication selected from the groupconsisting of ignored, changed, left alone and ignored for Queryoperations.
 18. The data structure according to claim 17, wherein: datarepresents multiple columns of a table structure.
 19. The data structureaccording to claim 8, wherein: the data structure is generated with aspreadsheet program and saved as comma delimited text files.
 20. A testscript for use with a scriptable test tool for testing the graphicaluser interface (GUI) of a software application comprising: a pluralityof library modules written in the scripting language of the scriptableGUI test tool, said library modules including a file which containsfunctions to handle the PreAmble and PostAmble actions of the testcases.
 21. A test script according to claim 20, wherein: said librarymodules includes a file which contains general functions that are alwaysapplication specific.
 22. A test script according to claim 20, wherein:said library modules includes a file which contains functions for allcommon procedure test cases and which controls the main flow and logicfor testing.
 23. A test script according to claim 20, wherein: saidlibrary modules includes a file which contains miscellaneous functionsto handle loading of GUI map files, opening of the specific test object,file I/O and several wait functions required during test execution. 24.A test script according to claim 20, wherein: said library modulesincludes a file which is loaded automatically by said scriptable testtool and which initializes physical GUI recognition parameters that havebeen carefully defined for the application.
 25. A test script accordingto claim 20, wherein: said library modules includes a file entitledwhich has two functions which are used to handle field value assignmentand validation based on input data.
 26. A test script according to claim20, wherein: said library modules includes a file which varies betweentesters at each different test site and contains several global variabledefinitions that allow an individual tester to specify alternateparameters and characteristics that may be unique to a location and orpurpose of a test.
 27. A test script according to claim 20, wherein:said library modules includes a file which defines all global variables.28. A test script according to claim 20, wherein: said library modulesincludes a file which provides parameter Set and Check functions.
 29. Atest script according to claim 20, wherein: said library modulesincludes a file entitled which provides an interface between individualBatch files and a test engine.
 30. A test script according to claim 20,wherein: said library modules includes a file which declares andinitializes global variables that are application specific forrecognition and processing of user actions.
 31. A test script accordingto claim 20, wherein: said library modules includes a file which uses asinput a Parameter File for an Object Under Test.
 32. A test scriptaccording to claim 20, wherein: said library modules includes a filewhich contains functions that are specific to dealing with pop-upwindows that are presented to a user during the course of the operationof the application under test.